This forum is closed to new posts and
responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:
I appreciate your concerns about rip and replace. But just because XPages is available, doesn't mean you have to completely redevelop your apps, as Tim Tripcony blogged recently http://www.timtripcony.com/blog.nsf/D6Plinks/TTRY-85LHLS. At the time I went on an XPages course last year I was revamping an existing web application, and had already got through a large amount of the work. It's still predominantly classic web, but I've used XPages for areas where the use of repeat controls made certain things MUCH easier (like editing multiple language keyword documents in a single interface, and changing an extremely unwieldy and inflexible agent that generated response forms and were limited to 250 questions to a repeat control that performed much better, had better scalability, and was easier to support). Users cannot tell any difference, and it was not too difficult, even on my first app, to reproduce the same look and feel.
Equally I have a very large client and web application with lots of lotusscript script libraries and custom classes. I haven't converted it to XPages and don't intend doing a full conversion any time soon. What I do plan on doing is possibly using XPages for the views or some other simple aspect of the application. Again, repeat controls could open a wealth of opportunities for innovative presentation techniques that could add significant benefit to the application.
For other Notes-based applications, I've created a separate searchable view of the content to plug into an intranet. No design elements have been added to that Notes database, all are in the intranet database.
For me, the key is using the right tools for the job. An XPage with a partial refresh and a few lines of SSJS allows me to develop much more quickly functionality that with AJAX would require javascript to call an agent, plus javascript to handle the response, and any errors. Thinking of performance, that is an agent running on the server. Not an issue if it's the only one, but have that application and server used by a lot of people, and the agent manager may become anissue. Factor in that someone (can't remember the blogger) researched that SSJS runs 4x quicker than LS or Java, and it's more scalable too.
Ctrl + S should work as long as the focus is in the Design or Source pane. I certainly had issues when the focus was in the wizards, but use Ctrl + S to save my XPages. Saving takes a long time on my home PC, but that's about 3 years old and was not designed to cope with The Eclipse client. My work PC was spec'd when we migrated to R8 to cope with the Eclipse client, and performance of saving is no different to what I used to have with classic Notes design elements.
I would disagree that Forms are the presentation layer. In XPages architecture they are for data entity structure, as equally are Views. You don't need a Form for XPages, but it enables the Designer client to understand your data model, so you get the right drop-downs. Equally, you could have a database with just a default view, and use repeat controls to display the content, doing a database.FTSearch to get your content, although you would need to sort it. The benefit of a view is it defines the sort order and index, making it easier to organise your data as you wish.
Feedback response number WEBB85SLG9 created by ~Maria Xanjumiberg on 05/25/2010